Business-to-business (i.e., ‘B2B’) applications are employed to manifest relationships between businesses and the like. Such relationships are typically governed by agreements such as contracts and the like which, among other things, define the rules governing transactions between businesses (e.g. ordering, payment etc.). Typically, a transaction is effectuated by exchanging electronic documents between parties, where the documents are representative of the transaction and are formatted according to a predefined protocol. Such protocol for example describes document formats, requirements, constraints, and the like.
In one typical B2B application, a supplier allows for the purchase of supplies by way of an automated purchase order (PO) entry system arranged to receive a PO from a customer, where the customer is physically remote from the supplier but able to access the supplier electronically, such as for example by way of a network such as the Internet. In particular, the supplier and the customer contractually arrange that the customer can purchase by way of an electronic PO transaction supplies from the supplier by way of the entry system, usually based on a pre-arranged line of credit. The PO is typically submitted to the supplier as an electronic document from the customer, and may be accompanied by a digital signature or the like to vouch that the PO is legitimate. The received signature is of a form recognizable to the supplier, identifies the customer, and is reviewed by the supplier (i.e., by the entry system of the supplier) to in fact establish whether the PO is legitimate. The supplier may confirm the PO by way of sending a corresponding electronic document to the customer, and may proceed to fulfill the PO.
As is known, the signature of the customer is based on a private key (PR-1) from a public key—private key pair established for the customer, and the corresponding public key (PU-1) of the user is in the possession of the supplier. Thus, the supplier (i.e., the entry system of the supplier) in receipt of the PO applies PU-1 to the signature to verify same. Public key—private key pairs and encryption are generally known and need not be described herein in any detail.
Owing to the fact that a relatively large customer may have several actual users of the PO entry system, and that the customer may not want to hand out PR-1 to each user, an arrangement has been devised wherein the customer gives each user a delegation document authorizing the user to execute a PO on behalf of the customer (i.e., ‘an authorization token’). In the arrangement, the authorization token includes a signature based on PR-1, and also includes a public key (PU-2) of the user from a public key—private key pair established for the user. In addition, in the arrangement, each PO submitted to the supplier by the user is accompanied by a digital signature based on the corresponding private key (PR-2) of the user.
Accordingly, the supplier (i.e., the entry system of the supplier) in receipt of the PO and authorization token from the user and still in possession of PU-1 applies same to the signature of the authorization token to verify same, obtains PU-2 from the authorization token, and applies same to the signature of the PO to verify same. Based on verification of both the authorization token and the PO, then, the supplier may then proceed to fulfill the PO.
However, an issue arises in that the authorization token as issued to the user essentially provides the user with the unlimited ability to submit POs, subject perhaps to any contractual limitations between the customer and the supplier. Thus, if a customer and a supplier do not contractually specify a maximum monetary value for each PO, a user in possession of an authorization token from the customer may in fact submit without constraint a PO having an inordinate monetary value. Correspondingly, if a customer and a supplier contractually specify a maximum monetary value for each PO that is relatively high, a user in possession of an authorization token from the customer may in fact submit a PO having the maximum monetary value, even if the user should not ordinarily have such a capability.
Accordingly, a need exists for a mechanism for applying monetary constraints to a user having an authorization token in the course of the user submitting a PO to a supplier based on the authorization token. More generally, a need exists for a mechanism for applying constraints both monetary and non-monetary to a user having an authorization token in the course of the user submitting a PO to a supplier based on the authorization token.